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Abstract 

We describe here a simple application of rational trees to the implementation of an inter- 
preter for a procedural language written in a logic programming language. This is possible 
in languages designed to support rational trees (such as Prolog II and its descendants), 
but also in traditional Prolog, whose data structures are initially based on Herbrand terms, 
but in which implementations often omit the occurs check needed to avoid the creation of 
infinite data structures. 

We provide code implementing two interpreters, one of which needs non-occurs-check 
unification, which makes it faster (and more economic). We provide experimental data 
supporting this, and we argue that rational trees are interesting enough as to receive 
thorough support inside the language. 

1 Introduction 

Occurs check, i.e., the need to verify whether a variable X occurs into a term T prior to 
performing the unification X = T (and failing if that is the case), is needed in order to 
provide soundness to logic programs based on first order logic. The need to check this can 
appears in general, when two terms have to be unified, as equations of the above form can 
be generated while unifying them. For example, solving 

f(X,X) = f(g(Y),Y) 

can be reduced to 

X = g(Y) 
X = Y 

which in turn boils down to X = g(X). The relevance of occurs check when reasoning on 
programs supposedly executing over the Herbrand domain can be seen from the following 
examples, taken from [CKS96]: 



Correspondence with First-Order Semantics Consider the statement 3z : p(z, z). It is not 
a logical consequence of Vx3y : p(x, y) (this is easy to see by taking p(x, y) as, e.g., y = x + 1 
in the domain of the natural numbers) . However, in the Prolog program 
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q:- p(X, X) . 

p(X, Y) :- Y = s(X) . 

the query ?- q. will succeed if occurs-check is not performed (as it is the default case 1 with 
many current Prolog compilers and interpreters). This means that Prolog without occurs- 
check is not adequate as a theorem prover for first-order logic. 

Program Transformation Some simple program transformations rely on occurs-check be- 
ing performed, or else the transformed program can behave differently from the original one. 
For example, the clause 

q(X, Y, U, V):- X = Y, X = a, U = f(X), V = f(Y). 

can be trivially transformed into 

q'(X, Y, f(X), f(Y)):- X = Y, X = a. 

The call 

?- q(X, Y, X, Y) . 

finishes with failure in all Prolog systems, but the call 
?- q> (X, Y, X, Y) . 

does not terminate in some Prolog systems, depending on how unification of circular terms is 
handled. 2 

Besides ensuring soundness, the assumption of the existence of occurs check makes it 
possible to carry around unification equations in solved form, i.e., in the form of a set of 
equations of the form Vavi = Terrrii where no Vari occurs inside any Terrrij. This permits, 
for example, projecting equations over variables (i.e., what a toplevel does to print answers) 
in a relatively straightforward way. Occurs-check is however not without a cost: checking for 
occurrences is, using a naive algorithm, quadratic with respect to the size of the terms to be 
unified. More refined algorithms can reduce the complexity to O(n) [MM76, MM821 IPW781I . 
but requiring large memory space or with a linear constant too high. This has somehow 
prevented the widespread use of occurs-check unification. Quoting IIALP 93 ] : 

An extreme example is append/3 for difference lists. Without the occurs check, the 
cost is 0(1); with the occurs check, the cost is 0{n) on the size of the terms (in other 
words, it gets the same cost as regular append/3). Normally, the programmer knows 
that the occurs check is not needed, so this is a big win. [P Ludemann] 

*It is to be noted that the ISO Prolog standard IDEDC96] does require the presence of a builtin 
(unif y_with_occurs_check/2) able to perform unification with occurs check. 

2 In particular, we have verified that Yap-5.4.1 and SWI-5.2.7 did not terminate, but SICStus and Ciao Prolog 
(which share an original common code base), did. Of course, newer versions of Yap and SWI may have already 
filled in this gap. 
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Benchmarking of Prolog systems which have included support for occurs check reports 
modest overheads in the execution (around 10%- 15% of global speed loss, with some studies 
reporting only 5% degradation [DRSW89]). While this might be seen as a relatively small 
price to pay, one might wonder if is worth paying it every time a unification takes place, 
especially taking into account that the programmer often knows where cyclic terms can be 
generated. Moreover, cyclic terms bring several useful characteristics, both in expressiveness 
and in performance, and we argue that they should be properly supported. Note that leaving 
the decision of performing or not occurs check to some analysis is not satisfactory, as the 
programmer may require it or not, so some sort of annotation guiding the compiler will be 
needed in that case. The analyzer might otherwise decide to include occurs check unification 
where they are not intended. In fact, as we will see, deciding where these are necessary is 
not straightforward, and different applications can be at odds with respect to the required 
behavior of, e.g., some library predicates. 

Not using occurs check at all changes the term universe, which must therefore be given 
a proper semantics with respect to unification and, if needed, with respect to difference con- 
straints. This has been studied elsewhere HCol84l ICol82a[ IJS8 61. and the resulting term 
universe has been named rational trees, as opposed to Herbrand terms. Rational trees are part 
of the design of, for example, the Marseilles family of Prolog systems [ Col 82bl |Col90l IPRQ1 
ICol961 IBT95II . Even if infinite, in the sense that there are paths of infinite length, rational 
trees can be finitely represented and used to represent cyclic data structures. 

There are practical reasons to allow the creation of cyclic terms. In practice, it seems 
that using rational trees does not need more resources than using Herbrand terms, and 
the necessary algorithms (not only unification, but also garbage collection routines, term- 
copying, and database modification predicates) can be effectively implemented. Rational 
trees have been explicitly used in graphics [ EC83 ] , parser generation and grammar manipu- 
lation [ Col8 2al IGC84II . computing with finite-state automata [Col82a], and several areas of 
natural language processing: rational trees are used in implementations of the HPSG (Head- 
driven Phrase Structure Grammar) formalism [PS84], in the ALE (Attribute Logic Engine) 
system ||Car92|| , and in the ProFIT (Prolog with Features, Inheritance and Templates) sys- 
tem [Erb95]. 

In this paper we present yet another application of rational trees: the implementation of 
interpreters for procedural languages featuring explicit control instructions (such as jumps, 
if -then-elses, whiles and repeats) which can divert the execution flow. Our aim is to im- 
plement an interpreter which is simple and easy to verify, but without sacrificing performance 
unnecessarily. Also, with the aim of producing an interpreter amenable to be analyzed and 
transformed, we want it to be as clean and trick-free possible. Some of the techniques we 
present can be performed using attribute variables [ Hol92 ] and occurs-check unification, but 
the resulting program is less amenable to automatic analysis and transformation. Describing 
it falls beyond the scope of this paper. 

In the rest of the paper we will first describe our initial problem (Section El) and then 
we will describe and evaluate two solutions (Sections |3] and 0J. We include code for the 
interpreters developed and for the benchmark programs. 
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label : instruction 


label is the address of instruction 


load <number> 


load <number> in the accumulator 


load <mem> 


load the contents of the address <mem> in the accumulator 


sto <mem> 


store the contents of the accumulator in the address <mem> 


add <number> 


add <number> to the accumulator and leave the result in the accu- 
mulator 


add <mem> 


add the contents of <mem> to the accumulator and leave the result 
in the accumulator 


sub <number> 


subtract <numb er> from the accumulator and leave the result in the 
accumulator 


sub <mem> 


subtract the contents of the address <mem> from the accumulator 
and leave the result in the accumulator 


jmp <label> 


jump to the instruction at the address <label> 


jez <label> 


jump to the instruction at the address <label> if the accumulator 
is equal to zero 


jnez <label> 


jump to the instruction at the address <label> if the accumulator 
is not equal to zero 


nop 


do nothing 



Table 1 : Syntax and (short) semantics of a simple language 



2 The Problem and the Target Language 

We want to interpret a procedural language using a (high-level) logic language (Prolog, in 
our case); there are several reasons to perform such interpretation: 

• We may want to execute programs in a language for which there is no compiler or 
interpreter available, and we do not want to invest time in writing a more sophisticated 
compiler. A simple interpreter might be enough for our purposes. 

• We may want to experiment with alternative semantics for the same (syntactically 
speaking) language. It is clearly much easier to do that if the interpreter is easy to 
understand and change. 

• We may want to apply analyzers written for the interpreter language to the interpreted 
language. This is possible by first unfolding the interpreter with respect to the inter- 
preted program, analyzing the resulting unfolded program, and then reinterpreting the 
analysis in the domain of the interpreted program. 

We will first set down a toy target language which notwithstanding features all the charac- 
teristics we need. For simplicity we will adopt an assembler-like language whose syntax and 
semantics are easy to describe. A summary of the (minimal) set of instructions we have cho- 
sen is shown in Tabled Figures |9[ 1101 and II II show several programs in the target language 
(those we have used to evaluate our implementations) . 

The target machine has a single register, the accumulator, which is used in all but two 
instructions, and which acts as implicit source and destination for data. Explicit data sources 
are either numeric constants (which appear directly in the code) or symbolic labels, which 
represent locations where the operands are stored. Data labels do not need to be declared, as 
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the assembler / interpreter assigns them a location. Data is loaded from implicit operands or 
from addresses into the accumulator; data in the accumulator can be stored in memory ad- 
dresses represented by labels. Arithmetic operations involve the accumulator both as source 
of values and as destination of results. The second operand for arithmetic instructions is 
explicit in the program source. 

Instructions can be labeled with a symbolic name which is used by control instructions; 
an unbound number of such label names are available. These labels appear as operands of 
jumps; unconditional jumps make the execution continue at the code associated to the label. 
Conditional jumps test the accumulator value and decide whether to continue executing on 
the next instruction of the program, or if execution has to divert to the instruction whose 
label is the operand of the jump instruction. There is no state register (usual in real micropro- 
cessors) which changes with the accumulator operations. There is also a no-op instruction. 
Execution starts in the first instruction of the program, and finishes when attempting to con- 
tinue executing after the last instruction. There is no halt instruction. 3 



program(f ibo , 

[jnez (calculate) , load(O) , sto(curr), jmp(end), calculate : sto (ind) , 
load(O) , sto(prev), load(l), sto(curr), start_loop : load(ind) , sub(l), 
sto(ind), jez(end), load(curr) , sto(inter), add(prev) , sto(curr), 
load(inter) , sto(prev), jmp(start_loop) , end: load (curr)] ) . 



Figure 1: Prolog representation of program in Figure [Tol 

We will assume that programs are already in the form of Prolog terms. Figure^Jrepresents 
the Fibonacci program in Figure [TO] as a fact, and every instruction is assigned to a Prolog 
functor. The interpreter and programs are designed to be used as 

?- program(f ibo , Program), interpret (Program, 400, A). 

where 400 is the initial value of the accumulator and A is the contents of the accumulator 
at the end of the execution. By convention we take the contents of the accumulator at the 
beginning of the execution as the input for the interpreted program, and its value at the end 
as the output value of the program, and we expect the programs to abide by this convention. 
We also assume that the programs are correct: for example, all labels to jump to appear in 
the program, there are no repeated labels, etc. The interpreter will otherwise fail. 

3 An Interpreter in the Herbrand Domain 

The two tasks the interpreter has to perform when executing the instructions are maintaining 
the memory state (including the accumulator) and deciding the next instruction to execute 
(and doing so) . Conceptually, the memory is a mapping 

label i— > value 

which relates every memory address name to a single value. This mapping is updated with 
every program instruction which stores a value into memory. Its implementation can be left, 
as we will do, to a table which takes the form of a Prolog dictionary, with the operations in 
table 

3 It may be replaced by making the last program instruction a nop and jumping to it. 
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interpret _nv (Program, Acln, AcOut) :- 
dic_empty (Dicln) , 

interpret_naive (Program, Program, Dicln, _DicOut, Acln, AcOut) . 

interpret_naive ( [] , _Program, _, _, Acum, Acum). 
interpret_naive ( [LI I Is] , Program, Dictln, DictOut, AIn, AOut):- 
remove_label(LI , I), 

executed, Is, Program, NProgram, Dictln, DictMid, AIn, AMid) , 
interpret_naive (NProgram, Program, DictMid, DictOut, AMid, ADut) . 

execute (load(NumOrLabel) , Is, _Program, Is, D, D, _, Value) :- 

eval (NumOrLabel , D, Value), 
execute (add(NumOrLabel) , Is, _Program, Is, D, D, Acln, AcOut) :- 

eval (NumOrLabel , D, Value), 

AcOut is Acln + Value, 
execute (sub (NumOrLabel) , Is, _Program, Is, D, D, Acln, AcOut) :- 

eval (NumOrLabel , D, Value), 

AcOut is Acln - Value, 
execute (sto (Label) , Is, _Program, Is, Din, DOut , Acum, Acum):- 

dic_replace (Din, Label, Acum, DOut). 
execute (jmp (Label) , _, Program, Is, D, D, A, A):- 

Is = [Label:_|_], append(_, Is, Program), 
execute (jez (Label) , NIs, Program, Is, D, D, A, A):- 

(A = -> Is = [Label:_|_], append(_, Is, Program) ; Is = NIs). 
execute (jnez (Label) , NIs, Program, Is, D, D, A, A):- 

(A \== -> Is = [Label:_|_], append(_, Is, Program) ; Is = NIs). 
execute(nop, Is, _Program, Is, D, D, A, A). 

remove_label (_ : I , I):- !. eval(Number, _Dict, Number):- 
remove_label (I , I). number (Number) . 

eval (Label, Diet, Number) :- 
atom (Label) , 

dic_get (Diet , Label, Number). 



Figure 2: An interpreter which does not need rational trees 

There is a similar relationship between program labels and program code: every program 
label maps into the sequence of instructions starting at the labeled one. With the current 
language, this mapping does not change and is explicit in the program text, so it is possible 
to search in the program text for the label to jump to when needed. Figure |2] portraits the 
complete code of an interpreter for the target language, which assumes that programs are 
already represented as in Figure Q] 

interpret_nv/2 traverses the program executing its instructions as they are found. When 
an instruction which has to store data in memory is found, the table which implements the 
memory is updated. The accumulator is explicitly passed around in a pair of arguments, 
corresponding to its state before and after executing each instruction. It could have been 
assigned a (designated) location in the table which represents the memory; however, as the 
accumulator is used in almost all instructions, having a direct access to it is reasonable and 
easy to code. Jumping to a label is performed by searching the corresponding point in the 
program. This makes the jump operation to have complexity 0(n), where n is the size (in 
instructions) of the program. This overhead does not affect the run-time complexity of the 
interpreted program, since the overhead is constant for every program, and does not change 
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dic_empty (T) 


Unifies T with and empty table 


dic_get(T,K,V) 


Unifies V with the value associated to the key K in table 
T; fails if K does not appear in T 


dic_replace (TIn,K, V,TOut) 


Replaces the value associated to K in Tin for V and unify 
the new table with TOut 


dic_lookup(T,K,V) 


Unifies V with the value associated to the key K in table 
T, and inserts the association if it does not exist yet 



Table 2: Table operations 



with the input arguments. 

We will not prove formally that this interpreter does not generate rational trees, but we 
will give some intuition supporting this. In the intended use of interpret_nv/3, the Program 
input argument is ground and Acln should also be ground, and both should be Herbrand 
terms. Therefore, in the interpret_naive/6 predicate the first, second, and fourth predicates 
should be ground. All the operations take place in execute/8, and in this predicate arguments 
1 to 4 and 7 are ground at call time. We need of course the code of the dictionary predicates 
to make sure that no cyclic terms are generated inside it, but we can give this for granted with 
a suitable implementation. The dictionary is used only to store (ground) values associated 
to (ground) keys and to retrieve them. Thus, the only unifications which take place in the 
interpreter have a ground term on one side of the equation, and no cyclic data structures can 
be generated. 

On the other hand it is straightforwar to make this program generate rational trees with 
a non-intended query: simply calling it as 

?- interpret_nv( [sto (where) ] , X, f(X)). 

will create a cyclic term. 

Table |3] shows the execution times for the interpretation of the programs in figures |9j 1101 
and 1111 The same data is depicted in Figure |3] (where the size of the input data has been 
scaled to the range [1.5, 7.0] so that the three graphs fit into the same figure). Time is in 
milliseconds, and was measured as the average of several runs. That figure alone is not really 
interesting, as it only shows the relative speed of different programs which makes different 
calculations. 
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Table 3: Execution times, interpreter free of occurs-check 
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Figure 3: Time evolution for the inter- Figure 4: Time evolution for the rational 

preter free of occurs-check tree interpreter 
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Table 4: Execution times for the rational tree interpreter 



4 An Interpreter Which Uses Rational Trees 

The overhead brought about by the search of the code to jump to can be diminished in several 
ways. Performance can be improved by, for example, storing program fragments in a table 
where labels are keys, and jumps would be preceded by a search for the correct fragment of 
code: 

execute (jmp (Label) , _, Code, D, D, A, A):- 
dic_get(D, Label, Code). 

Code has had to be associated to Label in a previous traversal of the program. However, 
this code performs an unnecessary search, since the representation of jump instructions (in 
fact, of every instruction) can be augmented to contain the code to be executed next, very 
similarly to a continuation passing programming style. Conditional jump instructions need 
two addresses for the then and the else branches, and the rest of the instructions need just 
one. For example, the program fragment 

[sto(ind) , load(0) , sto(prev) , load(l) , sto(curr), load(ind)] 

which does no have any jump instruction is translated by the predicate thread_program/2 
(Figure [5]) into 

sto (ind, load(0, sto (prev, load(l , sto(curr , load (ind, end) ) ) ) ) ) 
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interpret _thr (Program, Acln, AcOut):- 
dic_empty (ProgramDicIn) , 

thread_program (Program, ProgramDicIn, Threaded), 
dic_empty (MemDicIn) , 

interpret_threaded (Threaded, MemDicIn, _MemDicDut, Acln, AcOut) 
thread_program( [] , _, end). 

thread_program( [Inst I Next] , Diet, Threaded) :- 

thread_instruction(Inst , Diet, Threaded, RestThreaded) , 
thread_program(Next , Diet, RestThreaded). 



thread_instruction(Label : Instruction 
dic_lookup(Dict , label: Label 
thread_instruct ion ( Instruct i 
thread_instruction(load(What) , 
thread_instruction(sto (What) , 
thread_instruction(add(What) , 
thread_instruction(sub(What) , 
thread_instruction(nop, 
thread_instruction( jmp (Label) , Diet, 
dic_lookup(Dict , label: Label 
thread_instruction( jez (Label) , Diet, 
dic_lookup(Dict , label: Label 
thread_instruction( jnez (Label) , Diet 
dic_lookup(Dict , label: Label 



Diet, Threaded, RestThread) : - 
Threaded) , 
on, Diet, Threaded, RestThread). 
load(What, Next), Next). 
sto(What, Next), Next). 
add(What, Next), Next). 
sub(What, Next), Next). 
nop(Next) , Next) . 

jmp(Code) , _Next):- 
, Code) . 

jez(CodeYes, CodeNo) , CodeNo) :- 
, CodeYes) . 

, jnez(CodeYes, CodeNo), CodeNo): 
, CodeYes) . 



Figure 5 : Threading the code into a rational tree 



where the list structure is not needed any longer, since continuations are explicit in the repre- 
sentation of the instructions, and the pseudo-instruction end takes the place of the [] ending 
the program. Program fragments which have forward conditional jumps generate trees: the 
code 

[jez(is_zero) , load ( in) , is_zero : sub(acum) , sto(out)] 

translates into the tree (Figure [TJ) 

j ez ( sub (acum , sto (out , end) ) , load ( in , sub (acum , st o (out , end) ) ) ) 

where the subtree sub (acum , sto (out , end) ) appears twice and the labels are not needed any 
longer. 4 

A code which performs a jump backward in the code, such as 

[loop : load (data) ,sub(l) ,sto(data) , jnez(loop) ,load(in)] 

is translated into the rational tree (Figure [Hf 

load(data,sub(l,sto(data, jnez(load(data,sub(l,sto( ...))) ,load(in,end))))) 

where the dots abstract an infinite tree, but the whole term is a rational tree. A closer look 
at how threading is done reveals that the unification which constructs the cyclic term is per- 
formed inside the table implementation, in the first pass of the process which builds an (in- 
termediate) table associating labels with code. A trivial program such as loop: jmp (loop) 

4 In any modern Prolog system these two subtrees will be internally represented physically as the same data 
structure, so there is no waste of memory. 
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interpret_threaded(end, _, _, Acum, Acum) . 

interpret_threaded(Instr , Dictln, DictOut, AIn, AOut):- 

execute_threaded(Instr , Cont, Dictln, DictMid, AIn, AMid) , 
interpret_threaded(Cont , DictMid, DictOut, AMid, AOut) . 

execute_threaded (load (NumOrLabel , Cont), Cont, D, D, _, Value) :- 

eval (NumOrLabel , D, Value). 
execute_threaded(add(NumDrLabel , Cont), Cont, D, D, Acln, AcOut) :- 

eval (NumOrLabel, D, Value), AcOut is Acln + Value. 
execute_threaded(sub(NumOrLabel, Cont), Cont, D, D, Acln, AcOut) :- 

eval (NumOrLabel, D, Value), AcOut is Acln - Value. 
execute_threaded(sto(Label, Cont), Cont, Din, DOut, Acum, Acum):- 

dic_replace (Din, Label, Acum, DOut). 
execute_threaded( jmp(Cont) , Cont, D, D, A, A). 
execute_threaded(jez(Yes , No), Cont, D, D, A, A):- 

(A = -> Cont = Yes ; Cont = No) . 
execute_threaded(jnez(Yes, No), Cont, D, D, A, A):- 

(A \== -> Cont = Yes ; Cont = No) . 
execute_threaded(nop(Cont) , Cont, D, D, A, A). 



Figure 6: Interpreter for a rewritten program 




jezX-» , load (in, «^)^ 




Figure 7: Tree structure for a threaded program with jumps forward 

generates a rational tree due to the following table accesses and unifications (distilled from 
the execution of the interpreter) : 

dic_lookup(Dict , loop, Threaded), 
Threaded = jmp(Code), 
dic_lookup(Dict , loop, Code) 

which actually executes T = jmp(C) , T = C inside the code of dic_lookup/3. 

In return for the first pass which threads the code constructing the rational tree, the 
interpreter in Figure |6| is simpler than the one in Figure |2J as no searches for the labels are 
necessary: the code is directly accessible (in O(l)) in every instruction. This should bring 
performance advantages; this assumption is supported by the numbers put forward in Table[4] 
and shown in Figure|6l which are consistently better than the ones for the previous interpreter. 



load(data, sub(l, sto(data, jnez(... , load (in, end))))) 



Figure 8: Rational tree for a jump backwards 
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5 Conclusions 



We have shown two interpreters for an assembler language which differ in the way jump 
instructions are handled. The former performs linear searches (which can however be im- 
proved), and the latter performs a first pass which transforms the code into a rational tree 
which makes it possible to execute jumps in O(l). We have evaluated the performance of both 
interpreters, and the interpreter using rational trees outperforms considerably the Herbrand- 
based one. 

Therefore, using rational trees can bring benefits in terms of performance, and supporting 
them correctly in Prolog systems should make their use (and that of associated programming 
techniques) more widespread. However, giving full support is not straightforward, as many 
builtins will have to be ready to accept and process them correctly. The programming style is 
also affected, because base cases in recursion loops are not guaranteed to be reached, as they 
were with (ground) Herbrand terms. Additionally, there is no a priori way to detect, from the 
level of first order logic, that the predicate is looping with current LP systems. 

On the other hand, it does not seem to be a good idea to protect indiscriminately library 
predicates against creation of cyclic terms, for these predicates might be used to construct 
them on purpose, as in our case. It is true that hidden occurs checks can in some cases be 
overcome if desired, by extracting culprit unifications, e.g., by making 

dic_lookup(Dict , loop, Threaded), 
Threaded = jmp(Code), 
dic_lookup(Dict , loop, ThreadedCode) , 
Code = ThreadedCode 

instead of the code shown in section 0] This kind of transformations, which are correct if the 
called predicates are pure, can however lead to termination (and correctness) problems in 
non-pure predicates, and they have to be taken with a grain of salt. We deem much more 
useful to let the programmer to switch occurs-check on or off if necessary, maybe aided or 
guided by the results of program analysis. 



References 

[ALP93] The Occurs Check. ALP Newsletter, Volume 6/2, May 1993. Available at 

http : //www-lp . doc . ic . ac . uk/UserPages/staff /ft/alp/net/ impl/occur . html. 

[BT95] Frederic Benhamou and Touraivane. Prolog IV: langage et algorithmes. In 
JFPE95: TVemes Journees Francophones de Programmation en Logique, pages 51- 
65, Dijon, France, 1995. Teknea. 

[Car92] B. Carpenter. Cambridge Tracts in Theoretical Computer Science, volume 32, chap- 
ter The Logic of Typed Feature Structures with Applications to Unification-Based 
Grammars, Logic Programming and Constraint Resolution. Cambridge University 
Press, 1992. 

[CKS96] Lobel Crnogorac, Andrew D. Kelly, and Harald Sondergaard. A comparison of 
three occur-check analysers. In Static Analysis Symposium, pages 159-173, 1996. 



11 





sto 


accum 




load 


1 




sto 


factor 




load 







sto 


result 




load 


accum 




jez 


end 




sto 


ind 


loop : 


load 


result 




add 


factor 




sto 


result 




load 


factor 




add 


2 




sto 


factor 




load 


ind 




sub 


1 




sto 


ind 




jnez 


loop 


end: 


load 


result 



Figure 9: Squaring a number 
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end 
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ind 




load 
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load 
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load 


ind 




sub 
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ind 
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end 
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end: 
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Figure 10: Code for the Fibonacci func- 
tion 
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exit 


o_loop: 
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ind 
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i_loop: 
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ind 
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i_loop 
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sto 
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exit : 
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Figure 1 1 : Factorial program 
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